SSERelayDataStoreAdapter.Build now hands its existing wrapper to a
second SDK client (re-anchor handover) instead of constructing a
fresh wrapper around a fresh underlying store. The new anchor's
client therefore reads populated, initialized data immediately — no
empty-store window during re-anchor.

The wrapper is refcounted: each handover bumps the count via
acquire(); each client's Close decrements; only the final Close
tears down the underlying store. This honors design §7's
store-lifecycle caveat — Close must not tear down the shared store
while another client still holds it — without leaking the store on
final env teardown.

Two PoC tests that asserted the old broken behavior (H1 in-memory
sub-test, H5 in-memory wipe) are inverted to assert the post-fix
invariant. The spike test TestRealClient_HandoverScenarioToday is
renamed and rewritten to TestRealClient_HandoverPreservesUnderlyingStore
covering the full refcounted lifecycle.

…mitAnchor

Adds the API surface for the synchronous re-anchor sequence (design §7).

- Reconcile no longer flips r.primarySdkKey when the anchor changes.
  Callers receive a ReconcileResult carrying an AnchorChange struct
  (PreviousAnchor, NewAnchor, NewAnchorPreviouslyAccepted) and drive
  the flip via the new CommitAnchor(key) method once they are ready.
- ReconcileResult also exposes MobilePrimaryRepoint when the primary
  mobile key changed to a key that was already in the accepted set.
  In that case the key is not in additions and addCredential's gate
  won't fire, so the caller must invoke eventDispatcher.ReplaceCredential
  itself.
- env_context's reconcileCredentials applies the anchor change
  immediately after Reconcile to preserve pre-T2.c behavior. The full
  synchronous sequence (build new client first, then commit) lands in
  the next commit. The MobilePrimaryRepoint case is handled now —
  this is the fix for the gap left by PR #712's gate (already-accepted
  mobile key becoming primary skipped event-dispatcher repointing).

Two rotator tests that previously relied on Reconcile flipping the
anchor in place now call CommitAnchor explicitly with the returned
ReconcileResult.AnchorChange.

Implements the synchronous re-anchor sequence described in design §7.
reconcileCredentials now interleaves add → re-anchor → remove and owns
the new anchor's setup, replacing the prior commit's immediate
CommitAnchor.

The rotator strips the new anchor from additions in Case A so the
async startSDKClient invocation in addCredential cannot race the
synchronous client build. reanchor branches on whether a client
already exists for the new anchor:

  Case A (no client): install peripherals if the key is brand new
  (envStreams, handlers, connection mapping); construct the SDK
  client synchronously via c.sdkClientFactory with store handover
  (Build returns the existing wrapper, so the new client reads
  populated initialized data); on err or !Initialized, roll back —
  do not CommitAnchor, log a structured error, leave the previous
  anchor authoritative; on success, install the client, rebuild the
  evaluator, then CommitAnchor + ReplaceCredential + big-segment stub.

  Case B (client exists, e.g. a former anchor in grace): reuse the
  client and skip the build; CommitAnchor + ReplaceCredential +
  big-segment stub.

A new reconcileMu serializes concurrent reconciles without blocking
other env operations (GetClient / GetStore / addCredential continue
to run during the synchronous build).

Rotator-test updates: tests that previously expected the anchor in
the additions list now expect it stripped, and explicitly invoke
CommitAnchor mirroring what env_context's reconcileCredentials does.

T2.d (SDK-2543) will fill in reanchorBigSegmentSync; until then it is
a no-op (matching today's behavior — no regression on re-anchor).

Regression coverage for the synchronous re-anchor sequence (design §7):

- Case A success: re-anchor to a brand-new key builds a fresh client,
  hands over the store (same wrapper, still initialized, data intact),
  commits the anchor, and retains the old client during its grace
  period.
- Case A init failure: a failing new-client build rolls back — anchor
  pointer stays on the old key, no broken client installed, old client
  preserved, initErr surfaced.
- Case B: re-anchoring onto a key whose client still exists (a former
  anchor in its grace period) reuses the client and builds nothing new
  (clientCh stays empty), while the anchor flips.
- Mobile-primary repoint: switching the primary mobile key to an
  already-accepted mobile key repoints the primary without spawning an
  SDK client — the gap PR #712's gate left, now driven via
  ReconcileResult.MobilePrimaryRepoint.

All four pass under -race.

§7 previously described only Case A (re-anchor onto a brand-new key).
Add the Case B path — re-anchoring onto a key that already has a live
client (typically a former anchor still in its grace period): no
Build, no store handover, just the flip + ReplaceCredential + big-
segment re-wire that Case A also performs after init. The two paths
converge after the flip; the caller branches on c.clients[newAnchor].

Also clarify failure handling (rollback is Case A only; structured
Errorf log, no dedicated alarm infra), the Reconcile/additions
stripping interaction, and update the consolidated T2.c/T2.d
requirements table to reflect the case split and the synchronous
ReplaceCredential call site.

gofmt the rotator's removeCredentialFromList helper, and reword the
reanchorBigSegmentSync stub comment to avoid the godox TODO keyword
(godox is enabled in .golangci.yml; run.tests is false so only
production code is checked). No behavior change.

When a synchronous re-anchor's new client fails to initialize, reanchor rolls back and the environment keeps serving from the previous, still-valid anchor. It was also setting c.initErr to the new client's error — but the SDK returns ErrInitializationFailed for an invalid key, and the request middleware treats GetInitError() == ErrInitializationFailed as an env-level auth failure, returning 401 for every request. That rejected all traffic to an environment that was actually healthy, defeating the rollback at the HTTP layer.

Leave initErr untouched on rollback (the env is healthy on the old anchor); the failure still surfaces via the existing structured Error log. Update the Case A init-failure and PoC H7 regression tests to assert GetInitError() stays nil and that the failure is logged at Error level.

The cleanup ticker path (cleanupExpiredCredentials -> triggerCredentialChanges)
drained the rotator's StepTime queue and ran addCredential/removeCredential
without holding reconcileMu, so a credential expiry firing during an in-flight
synchronous re-anchor ran concurrently with the reanchor sequence. Both paths
drain the same StepTime queue (the ticker could steal additions a reconcile just
queued) and removeCredential could close a client mid-reanchor. The synchronous
re-anchor widened this window versus the pre-re-anchor base.

Take reconcileMu for the whole StepTime + add/remove pass in
triggerCredentialChanges so the ticker is serialized against reconcileCredentials
the same way concurrent reconciles already are. reconcileCredentials never calls
that path, so there is no re-entrancy.

Also gate re-anchor peripheral install solely on NewAnchorPreviouslyAccepted
instead of on the Case A/B client-presence branch. The two signals always agree
today (a client can only exist for a previously-accepted key), but branching
peripheral setup on the rotator signal means a brand-new anchor is never stranded
without its routing wiring even if that invariant were ever broken.

…nchorPeripherals

addCredential and the re-anchor path both need to register a credential's downstream-facing routing — the env-stream registration, per-stream-provider HTTP handlers, and the connection->env mapping. That logic was duplicated: addCredential inlined it and reanchor had a near-verbatim copy in installAnchorPeripherals.

Extract it into registerCredentialMappings(cred) (caller holds c.mu) and call it from both sites, removing installAnchorPeripherals. The name matches the codebase's existing 'credential mappings' vocabulary and replaces the ad-hoc 'peripherals' term throughout the comments.

In addCredential the connection-mapping registration now runs with the other two mappings (before the anchor/mobile switch) instead of after it. This is not observable: the whole function holds c.mu, and the SDK client is started asynchronously (startSDKClient builds the client before taking c.mu), so it installs only after addCredential returns regardless of internal statement order; the three registrations touch disjoint subsystems with no ordering dependency.

Two behavior-preserving simplifications of the re-anchor path:

- Extract buildAndCommitNewAnchorClient from reanchor: the ~45-line new-client build/rollback/install/commit block moves into its own method, leaving reanchor as a short four-way dispatch (register mappings, reuse existing client, offline commit, or build).

- Extract rebuildEvaluatorLocked, shared by startSDKClient and the re-anchor build path, which previously had a near-verbatim copy of the evaluator construction each.

Also clarifies two comments: the reanchor two-signal comment now explains that NewAnchorPreviouslyAccepted (were mappings already registered?) and existingClient (is there already a client?) answer distinct questions and legitimately differ when a previously-accepted non-anchor key is promoted; and restores the reconcileSDKKeys doc comment's opening line, which was dropped during the earlier catch-up merge.